Skip to content

Conversation

@ThomasBreuer
Copy link
Contributor

resolves #6200

Hopefully this is just a preliminary fix.
The change can be reverted as soon as large integers are allowed as bounds and length of ranges in GAP.

@ThomasBreuer ThomasBreuer added kind: bug Issues describing general bugs, and PRs fixing them kind: bug: unexpected error Issues describing bugs in which computation unexpectedly encounters an error, and PRs fixing them topic: library release notes: not needed PRs introducing changes that are wholly irrelevant to the release notes labels Jan 20, 2026
@ThomasBreuer
Copy link
Contributor Author

One CI test job is failing, "Validate release scripts".
As far as I understand, the code formatting in some python scripts is not acceptable, and "proper code formatting" is required for the test to pass.

How is this related to the current pull request?

Is this problem something that should be addressed in the current pull request, or is this a separate issue that should be fixed first, and then we run the CI tests again?

@ChrisJefferson
Copy link
Contributor

Yes, I'm not sure how that Python code got merged in, but it's obviously nothing to do with your PR.

@ChrisJefferson
Copy link
Contributor

I'm not saying we shouldn't merge this, but I made another PR adding 'large ranges' to GAP ( #6202 ), which also seems to fix this problem. Of course, we might decide that's too big a change.

@ThomasBreuer
Copy link
Contributor Author

@ChrisJefferson thanks.
As I wrote above, this pull request was intended as a hopefully preliminary solution (and can be used for a quick patch).
I would prefer to provide your "big ranges", provided that they do not affect the performance of the "small ranges",
but I leave the decision to the GAP kernel experts.

@ChrisJefferson
Copy link
Contributor

I'm really not sure why your PR is failing, because it looks fine to me when I run 'black' on the python files on my computer. Let's see if anyone else has a suggestion.

@ThomasBreuer
Copy link
Contributor Author

@ChrisJefferson Concerning the formatting problem: Your pull request #6202 shows the same failure.

@fingolfin
Copy link
Member

Ignore the formatting failures. My guess is: black (the Python code formatter we use) allows itself some "breaking" changes once each year; users have a choice of pining black to a specific "edition" / year, which we don't. So my guess is that the 2026 edition changes something.

Anyway: you don't need to worry about this.

Regarding large ranges: I don't think we'll have them soon, so we definitely don't want to wait for that, and need a workaround first.

@ThomasBreuer
Copy link
Contributor Author

Regarding large ranges: I don't think we'll have them soon, so we definitely don't want to wait for that, and need a workaround first.

So this pull request should be rebased (as soon as #6204 is merged), merged, and backported?

and make sure that the runtime is short
(this is of course cheating,
without the "hint" for `GlobalMersenneTwister` the runtime will
in general be much longer)
@fingolfin
Copy link
Member

Yes (although the rebase was not necessary, just closing&reopening would have sufficed) :-)

@fingolfin fingolfin enabled auto-merge (squash) January 23, 2026 17:06
@fingolfin fingolfin merged commit f7a40f7 into gap-system:master Jan 23, 2026
32 checks passed
@ThomasBreuer ThomasBreuer deleted the TB_ranges branch January 23, 2026 20:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

backport-to-4.15 kind: bug: unexpected error Issues describing bugs in which computation unexpectedly encounters an error, and PRs fixing them kind: bug Issues describing general bugs, and PRs fixing them release notes: not needed PRs introducing changes that are wholly irrelevant to the release notes topic: library

Projects

None yet

Development

Successfully merging this pull request may close these issues.

problem with ranges containing large integers

3 participants